 SFHack MODES Document                                                  v1.0
------------------------------------------------------------------------------
                                                             Copyright 1998-99
SFHack                                                          by Phil Holman
-------------------------------------------------------------------------------

This document contains descriptions and examples for the use of each mode
available in SFHack.

 CDC: Display World Championship match record
 CDT: Display Title match record

        This mode is used to display the information stored in one of the
   three World Championship or Title Match save slots, depending on which
   mode is specified on the command line. It is mainly provided for
   debugging SRAMs. The structure of the command line is as follows:

        sfhack [cdc|cdt] (SRAM) (Slot) (ROM)

        The SRAM and ROM components should both be acceptable filesystem
   paths. The SRAM provided is the SRAM to read the stored match record
   from. The Slot component specifies which record to try to read from
   the SRAM and must be in the range 0 - 2 (0 corresponds to the first
   slot). After reading the record, the ROM and SRAM are used to look
   up the current name(s) of the wrestler(s) competing in the specified
   record. All information is then printed to the screen along with tags
   to identify the value's meaning.

 CDO: Display Championship/Title match opponent list

        This mode is used to display a list of the opponents, in order,
   that a wreslter faces during the Championship or Title matches. The
   opponents are shown in a numbered list in which the number denotes
   the match number in which the opponent is the shown wrestler or
   wrestlers. The general syntax of the command line is as follows:

        sfhack (ROM) (Opponent Set) (SRAM)

        The SRAM and ROM components should both be acceptable filesystem
   paths. The ROM is used to read the opponent list specified by Set. The
   Set component should be an integer number between 0 and 11. For more
   information about which number corresponds to which list, see the CODES
   file. After reading the list, the mode decodes all character references
   in the list, using the ROM and SRAM to replace the reference with the
   wrestler's name that it references. Also, the index of the suit of the
   wrestler is shown in brackets after the wrestler's name.

 CML: Generate new Championship/Title match opponent list from file
 CRL: Generate new random Championship/Title match opponent list from file
 CTL: Generate new totally random Championship/Title match opponent list
      from file

        These modes allow the user to change the opponent lists for the
   World Championship and Title Match options in the game. The opponents
   to make the new list from are read from a list file. For examples of
   list files and a description of the structure that entries should
   conform to, see the example files in the LISTS subdirectory. An
   important note is that the SFHack generated lists CAN use SRAM characters
   in the tournament lists, if the user so specifies. This does lead to
   some possible complications that are discussed below. The general
   structure of the opponent list generation mode's command line is:

        sfhack [cml|crl|ctl] (ROM) (Opponent Set) (SRAM) (LISTFILE)

        The ROM, SRAM, and LISTFILE items must all be acceptable filesystem
   paths. The ROM is, of course, a path to the game ROM, where the new
   opponent list will be written. The SRAM is a path to the SRAM intended
   to be used during the tournament. The SRAM is needed because the utility
   needs to make sure that it does not allow a reference to an empty SRAM
   slot to be used in the tournament. All LISTFILE character references are
   checked when they are read. If an invalid reference is found, it is
   ignored and a message is printed to the system's standard error file
   (typically the screen) that states the line number where the reference
   occurs and why it is invalid.
        Due to the need to avoid having an opponent reference an empty SRAM
   slot, the original ROM opponent set should be restored before trying to
   use a different SRAM or after deleting or moving around characters so
   that slots are now empty that were not at the time of the list generation.
   An IPS patch to restore all of the six original opponent lists is provided
   in either the SFHack distribution in the IPS subdirectory or on the
   project's web site. If the new opponent list does not contain any SRAM
   character references, there is no possibility of a 'dangling' SRAM
   reference. In this case, the state of the SRAM and ROM is not a concern.
        The final component of the command line is the set identifier. The
   set should be either an integer between 0 and 11 or one of the special
   keywords, ALL or ALLTAG (they MUST be upper case). There are actually
   only six opponent lists in the ROM. These are the HWA, NHC, and HWGP
   singles opponent lists and the HWA, NHC, and HWGP tag team opponent
   lists. Originally, the developers probably planned to two different
   difficulty levels with different opponent sets. Regardless, in its
   current state, the ROM has two set references (integer indexes) that
   reference each opponent list. For example, the indexes 0 and 1 both
   reference the HWA singles list. For a list of what index corresponds
   to which list and how many opponents must be present to generate each
   list, see the CODES document. The special keywords ALL and ALLTAG are
   used to set all lists pertaining to either the singles or tag tournaments
   respectively. These special keywords are provided mainly to prevent
   individual opponents or teams from appearing in multiple federations
   in the same tournament (this is possible if you make the lists separately
   since the LISTFILE is reread each time). To set all lists of a specified
   type (single or tag), 104 LISTFILE character references are required.
   When replacing all lists, the lists are replaced in the order HWA,
   then NHC, and then HWGP.
        Now, there is also the question of the different modes. The
   different modes are provided to allow different methods of processing
   the LISTFILE. The CML mode reads the listfile and writes the opponent
   references found, in the order that they are read, into the opponent
   list. This allows the user to make a specific tournament list with
   the opponent order represented by the LISTFILE's reference order. The
   CRL mode, on the other hand is a random selection mode. In this mode,
   all LISTFILE references are processed and placed in a big pool of
   references. In the case of tag team lists, the CRL mode assumes that
   each pair of references are intended to be a tag team. One at a time,
   a wrestler or team, depending on whether the list is a singles or tag
   list, is selected randomly from the pool and used in the list, until
   the list is completed. Finally, the CTL mode is a second random mode
   in which the tag team assumption present in the CRL mode is dropped.
   In this mode, every wrestler is treated as an individual and the tag
   teams are selected by randomly selecting two wrestlers.

 DDB: Display the SRAM match defaults for the Battle Royal
 DDD: Display the SRAM match defaults for the Dream Match
 DDE: Display the SRAM match defaults for the Elimination

        These modes were test modes to make sure that my interpretation of
   that SRAM region was correct. After discovering the ability to disable
   the Lumberjack option for the Battle Royals, I decided to keep these modes
   in the utility so that users could double check the DSV mode before
   starting the SRAM (there is no telling what the emulators will do if an
   out of range value is written to one of the records). When these modes are
   invoked, the default record for the match type that is specified by the
   mode is read from the SRAM file and the information contained in it is
   dumped to the screen for the user to read. The general syntax of these
   modes is:

        sfhack [ddb|ddd|dde] (SRAM)

 DSV: Change a value in a SRAM match defaults record

        This is a general editing mode that I provided because I did not
   want to take the time to write ten different modes that did the same
   thing (like I did with the DDB, DDD, & DDE modes). This mode allows the
   user to choose one of the elements (bytes) in a match defaults record
   and write a new value in place of the current one. Originally, I had a
   restriction on this mode that would not allow locked attributes (those
   appearing as a "-" in the game) to be set using this mode. However, as
   long as the values are in the valid range for the option, the game seems
   to just ignore ones that should be locked (like when you specify a Count
   Out setting while Lumberjack mode is set to On). So, I dropped this
   restriction. The syntax of the statement is:

        sfhack dsv (SRAM) (Record) (Element) (NewValue)

        The SRAM argument is, of course, a path to the SRAM file that
   contains the record to modify. The Record, Element, and NewValue should
   all be raw codes. For the available values of these three arguments, see
   the CODES document. The Record is the index of one of the three match
   defaults records stored in the SRAM. The Element argument is the offset
   of the element to modify within the record specified by the Record
   argument. Since each record is only 17 bytes long, the Element argument
   may only be in the range 0 - 16. NewValue is the number to write into
   the specified element. The range of allowed values for the NewValue
   argument depends on which element is being written. See the CODES file
   for the meaning of each Element-NewValue combination.
        The main use I've found for the DSV mode is to turn off the
   Lumberjack switch in the Battle Royal match. This operation can serve
   as an example for how to use the mode. For, we get the CODES file and
   look for the correct Record. In the line, you'll see the lines:

   SRAM Defaults:
          0: Dream Match          1: Elimination          2: Battle Royal

   So, we want to set a Battle Royal element. Therefore, we want to use the
   index 2 to specify the Battle Royal record. Now, we need to know which
   element is the LumberJack switch. After looking in the Elements list, we
   find the entry:

       12: Lumberjack (0 -> Off, 1 -> On)

   So, the LumberJack setting is the element at offset 12. Also, in
   parentheses after the setting, we see the available settings (0 & 1)
   and what each means in the game. Since we want to turn the setting off,
   we will use 0 as the NewValue argument. Now, we have the command line.
   All we do is type it in. The final line would look something like this
   (assume the SRAM is in the current directory and is named "sfpwxp.srm"):

        sfhack dsv sfpwxp.srm 2 12 0

        By the way, make sure the Count Out value is set to Off. The Battle
   Royal matches incorrectly handle the match ending by Count Out. If the
   last wrestler or wrestlers are eliminated by Count Out, the match is ruled
   a Draw rather than a win by if one of the wrestlers was not counted out.

 ECR: Catalog ROM Elimination teams
 ECS: Catalog SRAM Elimination teams

        These two modes are provided to show a quick list of the Elimination
   teams available in the ROM (pre-made teams) and SRAM (edit teams)
   respectively. In the ROM mode, the teams are shown by their internal ROM
   index, while the SRAM mode version shows the teams by their slot number.
   These modes only show a team's associated index along with the team name;
   to see the members of a team, either the EDR or EDS mode should be used.
   Empty SRAM elimination team slots are use the UNUSED label in place of the
   team name. These modes are helper modes for the ROM edit team altering
   mode. Probably, no mode will be provided to set SRAM Elimination teams as
   this can be done in the game. The syntax of these modes is:

        sfhack ecr (ROM)
        sfhack ecs (SRAM)

 EDR: Show ROM Elimination team
 EDS: Show SRAM Elimination team

        These modes are used to show the members and name of a specific
   elimination team. ROM teams are specified by their internal offsets in
   the ROM while SRAM teams are specified using their slot number. To see
   what index number is associated with which team, use either the ECS or
   ECR modes. Because it is possible to use both SRAM and ROM characters
   in a team, even a ROM team, both the EDR and EDS modes require paths to
   both the ROM file and the SRAM file to be in the command line. The order
   that the paths are in on the command line depends on which file contains
   the actual Elimination team record. The syntax of the two modes is:

        sfhack edr (ROM) (Index) (SRAM)
        sfhack eds (SRAM) (Index) (ROM)

 ESR: Set ROM Elimination Team

        This mode allows the user to set up elimination teams to replace the
   pre-made ones in the ROMs. Unlike the existing ROM teams, the new teams
   may also contain characters from the SRAM. However, as with the opponent
   lists in the Championship and Title Match modes (See the CML/CRL/CTL
   entry), there is a danger when switching SRAMs or deleting characters from
   the SRAM. For this reason, the elimination teams should always be restored
   before using a different SRAM. (To restore the team names, the ROM must
   be re-patched with one of the NL-????.IPS patches.) The general syntax of
   the ESR mode is:

        sfhack esr (ROM) (Slot) (SRAM) (Name) (M1) (M2) (M3) (M4) (M5)

        The ROM and SRAM arguments are paths to the SFPWXP ROM file and the
   SRAM file from which comes any SRAM characters to include in the team
   (even if none are included, an SRAM file is still required). The Slot is
   the index of the ROM elimination team to write the new information to.
   There are 27 teams stored in the ROM and they are referenced by the indexes
   0 - 26.
        The rest of the information is the actual team data. The Name argument
   is a string of characters that represents the team's name. Since the string
   must conform to the available tiles in the game, the CODES document should
   be consulted before entering a name. Also, many letter tiles in the game
   are not available on a keyboard, so special sequences have to be used that
   are replaced by the string's processor with the actual tile code. All of
   the recognized character sequences are listed in the CODES document. Due to
   space restrictions in the label table and on the game screen, a team name
   cannot be more than 10 characters wide. If the name exceeds the limits,
   the process should get aborted automatically. As with the descriptive
   strings used stored with character modules, the team name should be
   enclosed in quotes to make sure that the shell interprets it as only one
   argument. Also, due to the name table not being set up for this mode until
   version 4 of the Japanese locale patches and version 3 of the English
   locale alpha patch, this mode should NOT be used with ROMs that are not
   using these patches or later ones.
        After the team name is the five members of the teams (in the same
   order as they would be entered in the Elimination Match setup). These
   five references must take the same form as the references contained in
   list files. For a description of this form, see one of the listfiles
   contained in the LISTS subdirectory or type 'sfhack esr' for the mode
   description.

 GCE: Convert the ROM character introduction records into English system
 GCM: Convert the ROM character introduction records into Metric system

        This mode was added as a side suggestion by a message board person
   (sorry whoever you are- I am bad when it comes to remembering names).
   Anyway, the modes are mainly just aesthetic. The original intentions was
   to convert the characters' heights from centimeters to inches and the
   characters' weights from kilograms (which is actually not a weight
   measurement) to pounds. This operation was done using the GCE mode. The
   GCM mode restores the records back to the Metric system versions (for
   those who don't know, meters and grams is the Metric measurement system
   while pounds and inches is the English measurement system). Unfortunately,
   during testing I realized that the weights could not be converted because
   the storage uses only one byte, which has a maximum value of 255. So for
   wrestlers heavier than 255 lbs, the value would rollover to 0 at 256.
   For example, a 300 lbs wrestler would actually be shown in the intro as
   being 44 lbs. So, the weight conversion was removed. Now the modes only
   convert the wrestlers' heights. The syntax of these modes is:

        sfhack [gce|gcm] (ROM)

 GCK: Recalculate SRAM checksum

        At the end of every SRAM is a two byte checksum that is used by the
   game to check for corruption (it prevents the game from crashing due to
   a messed up save RAM). Before being able to edit anything in the SRAM, I
   had to figure out how to recalculate this so that the SRAM wasn't reset
   when the game started. Well, obviously I did this. This mode only
   recalculates and writes the SRAM checksum and is mainly provided for
   people who want to attempt hex editor hacking of the SRAM. After playing
   with the SRAM, they will need to use this mode to set the checksum for
   the hacked SRAM. Otherwise, as I said, the game will clear the SRAM at
   startup. All of the SRAM-editing SFHack modes automatically set the
   checksum, so this does not need to be invoked after other SFHack modes.
   The syntax of this mode is:

        sfhack gck (SRAM)

 GDO: Show SRAM Options and Status

        This mode reads the current game options from the SRAM file and
   dumps the information to the screen. The options are all of the
   information available in the Options menu along with the status of the
   hidden flag, which is the flag that activates the hidden characters and
   moves. The syntax of this mode is:

        sfhack gdo (SRAM)

 GHA: Activate all SRAM hidden flags

        In each SRAM, there are two flags used to activate hidden features.
   The first flag activate the Title Match option in the menu and is set
   after a player wins the World Championship. The second flag makes the
   extra moves and characters available and is set after a player wins the
   Triple Crown in either tag or singles competition. This mode activates
   both of these flags, making all of the hidden game options available.
   The syntax for this mode is:

        sfhack gha (SRAM)

 GRC: Recount the number of SRAM characters

        The SFPWXP game uses counters to control how many characters to
   display in each federation. Since the Edit wrestlers in the SRAM are
   grouped as a federation, the SRAM has to keep a count of the number of
   existing wrestlers. When editing wrestlers within the game, this is all
   done transparently. However, when dealing with SFHack and other outside
   editing utilities, there may occasionally arise a situation where not
   all characters, stored in the SRAM, appear in the Edit federation at
   the selection screen. If this happens, it is probably due to the count
   being incorrect. This mode recounts the number of active SRAM slots and
   writes the count to the SRAM. The syntax of this mode is:

        sfhack grc (SRAM)

 MCC: Catalog all records contained in a module file

        This mode catalogs module files, created and manipulated using SFHack,
   by showing each record's index followed by its three identification string
   values. The syntax of this mode is:

        sfhack mcc (MODULE)

        For an example of how the output from this mode looks, see the below
   example that shows the MCC output for the HOGAN.FPM module file contained
   in the EXAMPLE subdirectory.

 MCR: Write ROM character to module
 MCS: Write SRAM character to module
 MRS: Refresh dumped SRAM character  

        These two modes are the centerpoint and main purpose of the SFHack
   utility. Using these modes, the user can copy a character from the ROM
   or the SRAM into an independent file. At any time, this character can then
   be copied back from the module file into an SRAM edit slot in a matter of
   seconds. This ability allows users to mix and match characters in the SRAM
   on-the-fly, without having to deal with referencing templates or entering
   all of the character information again. The module files in which the
   characters are stored by these modes may contain any number of characters,
   allowing users to store the characters in individual module files or in an
   archive-like module that contains all of the available SRAM characters.
   Due to the possibility of confusion for archives containing multiple
   wrestlers, I decided that some extra information was needed to help
   distinguish between the different characters without having to restore
   them in an SRAM. After some thought on the matter, I decided to store three
   descriptive strings along with the character data. The strings would hold
   information to describe the character, the suit of the character, and the
   person who created the character. The latter of the three is provided in
   case a person wishes to archive different people's versions of a particular
   wrestler. Later, I decided to add the MRS mode, which is an SRAM character
   to module dumping mode that does not require the three identification
   strings, because it only allows dumping into an existing record (it is
   intended for redumping SRAM characters that have been updated). The syntax
   of the two modes is:

        sfhack mcr (ROM) (Slot) (Outfit) (Name) (Suit) (Maker) (Module) (Rec)
        sfhack mcs (SRAM) (Slot) (Name) (Suit) (Maker) (Module) (Rec)
        sfhack mrs (SRAM) (Slot) (Module) (Rec)

        In the above command lines, the ROM and SRAM items are paths to the
   SFPWXP ROM and SRAM files respectively, while Slot is the number used to
   identify which character is to be copied to the module. In the case of the
   ROM, the character index is the internal index used to identify the
   character. The list of ROM character indexes appears in the CODES document.
   In the case of the SRAM, on the other hand, the character slot is literally
   the number of the SRAM edit slot that holds the character. For the ROM
   character mode, an extra argument, Outfit, must be specified. The reason
   for this is that ROM characters have four different suits, each with an
   accompanying color scheme, while an SRAM character, by default, only has
   one (supposedly, the Turbo File allows multiple suits for SRAM characters,
   but it has not been and probably will never be emulated).
        The Outfit argument is the index of the suit to use when copying the
   character (character modules use the SRAM format for quicker insertion and
   copying, so only one suit is stored in a character module). When in the
   game, the initial ROM character suit that is visible on the character
   selection screen is suit 0. After selecting the character, you can press
   right to cycle through the other suits in order.
        The Name, Suit, and Maker arguments are the three descriptive strings
   mentioned above. Keep in mind, these three strings are only to identify
   the character record stored in the module slot and have no direct bearing
   on the character record. Each of these three arguments is a string and
   should be surrounded by quotes if they contain embedded spaces. For
   example, to use Kevin Sullivan as the Name, it should be written as
   "Kevin Sullivan" (this is why I put quotes around these arugments in the
   usage of the mode). Also, due to the shell's handling of the double quotes
   ("), quotes within the identification strings should be either a single
   quote (') or apostrophe (`). For example, to use Bret "The Hitman" Hart as
   the name, enter it as "Bret 'The Hitman' Hart" and NOT "Bret "The Hitman"
   Hart". Each string allows up to 39 characters. Do NOT exceed this length-
   to do so could corrupt the other strings and character data. (In v0.62,
   I set this so that strings longer that 39 characters are truncated to 39
   character, but older versions of SFHack do NOT truncate.)
        The Module and Rec arguments are the module file and the record index
   in the file (starting at 0) to write the character to. When writing a
   character INTO a module file, the Rec can be any of the existing module
   record slots or the next, currently non-existant slot. For example, if you
   wanted to create a new module file, which means the file currently contains
   0 records (because it doesn't exist yet), then you want to write to slot
   0 in the module file (the module file will be created by SFHack). On the
   other hand, if the file already contained 4 characters, then the Rec
   values 0-3 could be used to copy the new character over one of the existing
   four records or a Rec value of 4 could be used to add the character as a
   new record, making the module file contain 5 records.
        Since these are the most important modes in the game, I'll go through
   a general example of how to use these modes. For the example, I'll use ROM
   characters (for simplicity) and run through how to dump all suits of a ROM
   character. For the example, I am going to use Hulk Hogan (ROM #62). Now, to
   start off with, we'll just start by dumping the first suit, which will also
   create the module. To be able to find it later, I think I'll call the
   module HOGAN.FPM, where the .FPM extension stands for Fire Pro Module. Now,
   the first Hogan suit (0) in the game is his old trademark yellow & red
   Hulkamania outfit. So, for the suit name, I'll use "Hulkster - Yellow &
   Red". So the first command line is (Due to the lengths of the commands, I
   have to show the command on two lines. When entering the commands, do NOT
   hit enter until the entire command is in.):

        sfhack mcr sfpwx.fig 62 0 "Hulk Hogan" "Hulkster - Yellow & Red"
        "Human (ROM)" hogan.fpm 0

   So, now there should be a file called HOGAN.FPM. If you use the MCC mode
   with HOGAN.FPM as the module file, you should see the listing:

        Index:      Character Information:
             0: Hulk Hogan / Hulkster - Yellow & Red / Human (ROM)

   As you can see, the three strings shown in the module listings are the
   three identification strings entered during the character dump. Now, we
   still have three other suits. Since we want to store all of the suits in
   the module file, the next three suits should be written to module records
   1, 2, & 3 respectively (remember that you can only write to up to one
   record after the end of the module file, so we have to dump the characters
   to those slots in that order). Now the second Hogan suit is the black
   trunks. I have never seen him wearing these, so I don't know what persona
   he was in at that time, so I'll use a generic suit reference like "Black
   Trunks". The third suit has Hogan back before the bleach-blonde look. From
   what I've heard, Hogan once wrestled under the name Terry Boulder. I think
   this may be the suit, but I could be wrong. So just in case, I'll use a
   generic reference for this one too, like "Brown Hair & Yellow Trunks". The
   last Hogan suit is a white trunks outfit, like the ones Hogan was wearing
   in his Rocky appearance as Thunderlips. However, since I don't know whether
   or not he actually wrestled in these (though he probably did), I'll just
   use another generic description, "White Trunks". So the next three
   commands, in order, are:

        sfhack mcr sfpwx.fig 62 1 "Hulk Hogan" "Black Trunks" "Human (ROM)"
        hogan.fpm 1

        sfhack mcr sfpwx.fig 62 2 "Hulk Hogan" "Brown Hair & Yellow Trunks"
        "Human (ROM)" hogan.fpm 2

        sfhack mcr sfpwx.fig 62 3 "Hulk Hogan" "White Trunks" "Human (ROM)"
        hogan.fpm 3

   Now, when you use the MCC mode to catalog the HOGAN.FPM module, you see:

        Index:      Character Information:
             0: Hulk Hogan / Hulkster - Yellow & Red / Human (ROM)
             1: Hulk Hogan / Black Trunks / Human (ROM)
             2: Hulk Hogan / Brown Hair & Yellow Trunks / Human (ROM)
             3: Hulk Hogan / White Trunks / Human (ROM)

   That's all there is to it! Before someone emails me saying this doesn't
   work, I put the HOGAN.FPM file created using this in the EXAMPLES
   directory. Other than the possibility of a typo, this example is correct.

 MSI: Change Module character's ID strings

        This mode allows the user to change the three ID strings stored with
   a module character record without altering the character data stored in
   the record. This is provided in case a user decides to be more descriptive
   with the suit description or accidentally mixes up two character slots,
   dumping each with the ID strings intended for the other slot. As with
   other module record modes, the path to the module and the index of the
   record are required to specify the module record. In addition to these
   arguments, the mode also requires the three new values for the ID strings
   that will replace the current strings stored in the record. The syntax
   of this mode is:

        sfhack msi (Module) (Rec) (Name) (Suit) (Maker)

 MCM: Copy module record

        This mode allows the user to copy one module record to another
   location. (Actually, the user could copy the record over itself if he wants
   to ;-) The MCM mode requires two module file & record pairs, one to locate
   what record is being copied and the one to locate the destination to write
   the record to. Obviously, unlike the destination record, the source record
   MUST be an existing module slot. The syntax of this mode is:

        sfhack mcm (DestModule) (DestRec) (SourceModule) (SourceRec)

        For a description of how to specify the destination module and record
   pair, see the entry MCR/MCS entry. The source module and records must be
   an existing module file and an active module record in that file. This mode
   copies the entire module record to the specified destination, including the
   identification strings.

 MDC: Show module record character information
 RDC: Show ROM character information
 SDC: Show SRAM character information

        These three modes are used to view the character information stored
   in ROM character records, SRAM character records, and module records. For
   each of these modes, a pair of arguments must be provided to locate the
   record to show. For ROM characters, the path to the ROM file along with
   the ROM character index (available in the CODES file) of the desired
   character is used to locate the character record. For SRAM characters,
   the path to the SRAM file and the number of the edit slot containing the
   character is required. And for module records, the path to the module
   file and the index of the record is required. The syntax of each of these
   three modes is:

        sfhack mdc (Module) (Rec) (Flags)
        sfhack rdc (ROM) (Index) (Flags)
        sfhack sdc (SRAM) (Slot) (Flags)

        The final argument in each of these modes is the display flags. This
   argument controls what data is shown and consists of a string of character
   flags. The available flags are n (Name), m (Make), k (Skills), s (Stats),
   v (Moves), and l (Logic). For example, to see just the name and make of the
   first edit slot character in an SRAM named sfpwxp.srm, the following
   command could be used:

        sfhack sdc sfpwxp.srm 1 nm

 MDT: Show module record character title status
 RDT: Show ROM character title status
 SDT: Show SRAM character title status

        These three modes are used to view the character title status stored
   in SRAM character records and module records. For each of these modes, a
   pair of arguments must be provided to locate the record to show. For ROM
   characters, the path to the SRAM file along with the ROM character index
   (available in the CODES file) of the desired character is used to locate
   the character record (ROM character title statuses must be stored in the
   SRAM since you can't write to ROM files). For SRAM characters, the path to
   the SRAM file and the number of the edit slot containing the character is
   required. And for module records, the path to the module file and the
   index of the record is required. The syntax of each of these three modes
   is:

        sfhack mdt (Module) (Rec)
        sfhack rdt (SRAM) (Index)
        sfhack sdt (SRAM) (Slot)

 MSF: Set module record character finishers
 RSF: Set ROM character finishers
 SSF: Set SRAM character finishers

        These three modes are used to set a character's finishers. The game's
   character structures were originally designed to store up to three
   finisher categories. This was due to the ability to do the same move from
   multiple positions. However, since a move being a "finisher" appears to
   only make the move slightly more powerful- this array of categories can be
   used to mark the character's trademark holds. The finishers are specified
   by the index of the move's category (available in the CODES document). For
   no finisher, a value of -1 should be entered. For example, to denote that
   the only finisher of the character is in the general special category (51),
   the following three references would be used for the finisher arguments:
   51 -1 -1.
        For each of these modes, a pair of arguments must be provided to
   locate the record to show. For ROM characters, the path to the ROM file
   along with the ROM character index (available in the CODES file) of the
   desired character is used to locate the character record. For SRAM
   characters, the path to the SRAM file and the number of the edit slot
   containing the character is required. And for module records, the path to
   the module file and the index of the record is required. In addition to
   the character identifying information, a raw title Code must be provided.
   This Code is the value written to the record as the new status. For a
   description of the title codes, see the CODES document. The syntax of each
   of these three modes is:

        sfhack msf (Module) (Rec) (Fin1) (Fin2) (Fin3)
        sfhack rsf (ROM) (Index) (Fin1) (Fin2) (Fin3)
        sfhack ssf (SRAM) (Slot) (Fin1) (Fin2) (Fin3)


 MST: Set module record character title status
 RST: Set ROM character title status
 SST: Set SRAM character title status

        These three modes are used to set the character title status stored
   in SRAM character records and module records. For each of these modes, a
   pair of arguments must be provided to locate the record to show. For ROM
   characters, the path to the SRAM file along with the ROM character index
   (available in the CODES file) of the desired character is used to locate
   the character record (ROM character title statuses must be stored in the
   SRAM since you can't write to ROM files). For SRAM characters, the path to
   the SRAM file and the number of the edit slot containing the character is
   required. And for module records, the path to the module file and the
   index of the record is required. In addition to the character identifying
   information, a raw title Code must be provided. This Code is the value
   written to the record as the new status. For a description of the title
   codes, see the CODES document. The syntax of each of these three modes is:

        sfhack mst (Module) (Rec) (Code)
        sfhack rst (SRAM) (Index) (Code)
        sfhack sst (SRAM) (Slot) (Code)

 MEC: Erase module record destrucively
 MES: Erase module record safely
 MUC: Unerase module record

        The modes are provided to allow the user to delete module records.
   Basically, whenever making a format, like the module format, you should
   always provide some basic utilities for them, like copying and deleting.
   There are two delete modes, MES and MEC, which differ in the method of
   deletion. The MEC mode actually overwrites the record data so that the
   record is not recoverable using the MUC mode. The MES mode, on the other
   hand just toggles the record active flag without disturbing the record
   data. This allows the record to be restored using the MUC mode, which
   toggles the active flag back to active if the record appears to be intact.
   The syntax of all three of these modes is:

        sfhack [mec|mes|muc] (Module) (Rec)

        Each of these modes requires the use to provide the path to the module
   file containing the record and the record offset in that file. Of course,
   the record specified for the MEC or MES modes should be an existing and
   active record, while the record for the MUC mode should be an existing but
   non-active record.

 MPF: Preprocess file with module record character information
 RPF: Preprocess file with ROM character information
 SPF: Preprocess file with SRAM character information

        These three modes are used to fill in generalized forms with data
   from a particular character. This was the solution I came up with when
   faced with the problem of character templates. Using these modes, templates
   can be designed using general macros of the form $$(TAG) that are replaced
   when the File is processed with these modes. This also provides a nice
   method of setting up batch files (for example, see the NEWMOVES.BAT
   template in the BATCH directory). Some examples of template files are
   stored in the EXAMPLES directory. When the File is processed, the File's
   contents, with the macros replaced, is dumped to the screen, where it
   can be redirected to a new file. See the MACROS file for a list of macro
   tags and a description of the information used to replace the tag. Tags
   that are not recognized are simply removed.
        For each of these modes, a pair of arguments must be provided to
   locate the record to show. For ROM characters, the path to the ROM file
   along with the ROM character index (available in the CODES file) of the
   desired character is used to locate the character record. For SRAM
   characters, the path to the SRAM file and the number of the edit slot
   containing the character is required. And for module records, the path to
   the module file and the index of the record is required. The syntax of each
   of these three modes is:

        sfhack mpf (Module) (Rec) (File)
        sfhack rpf (ROM) (Index) (File)
        sfhack spf (SRAM) (Slot) (File)

        Here's an example of how to make an HTML file from a template. For
   the example, I'll use the ROM-EX.HTM file included in the EXAMPLES
   directory. This file is intended to store ROM character information. For
   my example, I'll use Hulk Hogan's (ROM #62) information to fill the
   template's macros. Since Hogan's a ROM character, the mode to use is RPF.
   Now, to identify the file, I'll call the filled template R-HOGAN.HTM. The
   command line I use is:

        sfhack rpf roms\sfpwx.fig 62 examples\rom-ex.htm > r-hogan.htm

 MMC: Combine multiple module files into one file

        This mode creates a single module file containing all records from a
   list of module files. That's it! Nothing special- just a CAT utility for
   modules. The syntax of the mode is:

        sfhack mcc (CombinedModule) (Module1) ... (ModuleN)

 MSM: Set module record character move
 RSM: Set ROM character move
 SSM: Set SRAM character move

        These three modes are used to set a character's move for a specified
   category. For each of these modes, a pair of arguments must be provided to
   locate the record to show. For ROM characters, the path to the ROM file
   along with the ROM character index (available in the CODES file) of the
   desired character is used to locate the character record. For SRAM
   characters, the path to the SRAM file and the number of the edit slot
   containing the character is required. And for module records, the path to
   the module file and the index of the record is required. In addition to the
   character identifying information, a raw move Category and Code must be
   provided (and possibly a Special move category if the move being set is
   in Category 51, the general Y+B special). The move Categories, raw Codes,
   and Special categories are all listed in the CODES file. In this mode,
   there is no restriction to stop you from writing moves that don't work and
   may lock up the game- so choose carefully. The syntax of each of these
   three modes is:

        sfhack msm (Module) (Rec) (Category) (Code) [Special]
        sfhack rsm (ROM) (Index) (Category) (Code) [Special]
        sfhack ssm (SRAM) (Slot) (Category) (Code) [Special]

 RCC: Catalog all characters contained in the ROM

        This mode catalogs ROM characters. Originally, I made this mode as a
   helper mode during the time that I was trying to figure out whether or not
   the ROM characters could be easily changed. This listing is equivalent to
   the ROM character code listing in the CODES file, but this listing will
   show the current names of the wrestlers as specified in the ROM (which can
   help to figure out what patches are on the ROM). The syntax of this mode
   is:

        sfhack rcc (ROM)

 RDI: Display ROM introduction record information

        This mode displays the information stored in the ROM introduction
   records. There is one record for each pre-made ROM character (104 in all).
   As with the ROM character records, the introduction records require the
   path to the ROM and an Index in the range 0-103 to identify the intro
   record to display. This mode was added as a setup for the Bruiser Brody
   patch fix that stops the lock-up that occured during the introduction. The
   syntax of the mode is:

        sfhack rdi (ROM) (Index)

 RSB: Set ROM character's body graphic
 RSC: Set ROM character's suit colors
 RSN: Set ROM character's stance
 RSS: Set ROM character's suit
 RSZ: Set ROM character's body component sizes

        The RSC mode allows the user to change the colors associated with one
   of a ROM character's four suits to a new series of color table references.
   The color table is where the color combinations are stored that are
   available in the Make Menu (the non-Custom indexed color combinations with
   the labels like Har and Skn). This mode is meant to be used with the RSS
   mode to alter the ROM character suits. The RSS mode is used to change the
   components of the character's suit. Before trying to run the modes, the
   user should setup the new suit in the game's Make Menu so that all of the
   data needed by these two modes is known. When dealing with locked entries
   in the color set (those appearing as '-'), try changing some suit
   component's around so that they can be changed. Then make sure that they
   are indeed the proper color index (I had problems with this during testing,
   but did get it to work eventually). Due to the intended purpose of these
   modes, I made a batch file for creating new suits called NEWSUIT.BAT. This
   file is contained in the BATCH directory and contains labelled variables
   to hold the information for these commands. This batch file also contains
   multiple examples of how to make new 'suits'. The file acts like a library
   and can have any number of suit sets. See the file for more information.
   I have now added modes to change a ROM character's body graphic, body size,
   and stance to allow more manipulation of the ROM character's suits. The
   modes to manipulate these features are RSB, RSZ, and RSN respectively. As
   with the other modes mentioned, I recommend that you make the character in
   the editor and have the information written down before attempting to use
   the modes. These modes use the following syntaxes:

        sfhack rsb (ROM) (Index) (Body)
        sfhack rsc (ROM) (Index) (Suit) (Skn) (Har) (Lin) (Tgt) (Pnt) (Fet)
        (Shn) (Pad)
        sfhack rsn (ROM) (Index) (Stance)
        sfhack rss (ROM) (Index) (Suit) (Outfit) (Pants) (Tights) (Pads)
        (Shin) (Feet)
        sfhack rsz (ROM) (Index) (ThighSz) (BodySz) (StomachSz) (ChestSz)

        The ROM and Index arguments are the path to the ROM file and the ROM
   character's index that locates which character to write the suit to. The
   Suit argument is also an index in the range 0-3 that denotes which ROM
   character suit to overwrite with the new information. The rest of the
   information comes from the Make Menus. The Color indexes come directly from
   the menus, while the suit components must be entered as numeric values. See
   the NEWSUIT.BAT file for a list of the numeric values associated with each
   suit component. When setting up new suits, make sure to NOT enter an
   undefined value (for example, don't use a value of 10 for the Tights
   component). I have checked and found no extra suit components. When out
   of range values are entered, the ROM does strange things. The Body argument
   to RSB is the raw index for the body graphic. These indices can be found
   in the CODES document. This index is NOT the number of the graphic from the
   edit menu. (The body graphic is index the same as the one that you would
   use with the SSP option.) As I've stated before, you cannot change the
   portrait used by a ROM character due to the way the ROM finds the ROM
   character's colors internally. Also, you cannot change the ROM character
   names "on-the-fly" due to an inability to guarentee that the label table's
   structure has not been screwed up by the operation, so don't email me
   asking how to do this. The Stance argument, like the body graphic argument,
   can be found in the CODES document. It specified the Stance used by the
   wrestler, but like the category in the EDIT menu. Finally, the four sizes
   that are arguments to RSZ are the four sizes that appear in the EDIT menu
   also. To make it easier to work with, I've allowed the use of letters
   rather than codes so that you can enter either S, M, L, or X as each size.
   The limitations present in the EDIT menu are checked by the utility to
   make sure that something invalid isn't written, such as a S thigh size.
   Note that the sizes appear in a DIFFERENT ORDER than the sizes in the
   EDIT menu, so you need to pay attention to which size goes with which
   argument. Also, notice that LL is not a valid argument. For simplicity,
   I limited the arguments to 1 letter each, so I use X to represent Extra
   Large, which is listed in the edit menu as LL. If you enter LL as the
   argument, the utlility will think you mean Large (L).

 SEC: Erase SRAM record destrucively
 SES: Erase SRAM record safely
 SUC: Unerase SRAM record

        The modes are provided to allow the user to delete and restore SRAM
   records. I made this mode after accidently deleting the wrong SRAM slot.
   When I visually inspected the record, it was still intact, so I just
   toggled the active flag back to on and my character was fine. Yeah! So, I
   adjusted the existing MEC, MES, and MUC modes to produce SEC, SES, and
   MUC, which are the equivalents to the module versions, back act on SRAM
   character slots rather than module records. The in-game slot deletion is
   equivalent to using the SES mode. For a description of the effect of each
   mode, see the MEC/MES/MUC entry. The syntax of all three of these modes is:

        sfhack [sec|ses|suc] (SRAM) (Slot)

 SCC: Catalog all characters active in the SRAM

        This mode catalogs SRAM characters, making it possible to view the
   contents of an SRAM without having to run the emulator. For records that
   are inactive, a special label (like EMPTY) is used to denote this.
   Otherwise, the character name stored with the character's record is shown
   beside the slot number. The syntax of this mode is:

        sfhack scc (SRAM)

 SCM: Copy module character record into SRAM slot
 SCR: Copy ROM character record (one suit) into SRAM slot
 SCS: Copy SRAM character record into SRAM slot

        These modes are used to copy a character record from either a module
   file, ROM record, or another SRAM record. A SRAM path and Slot combination
   are needed to locate the destination to where the record should be copied.
   For an SRAM source, a second SRAM patch and Slot are needed to locate the
   source of the record to copy. For a ROM source, the ROM patch and ROM
   character index is needed along with the index to one of the four character
   suits (SRAMs only allow one suit) to specify the character information to
   copy. For a module record source, the module path and Index of the module
   record to copy is needed. The syntax of these three modes is as follows:

        sfhack scm (SRAM) (Slot) (Module) (Rec)
        sfhack scr (SRAM) (Slot) (ROM) (Index) (Suit)
        sfhack scs (DestSRAM) (DestSlot) (SrcSRAM) (SrcSlot)

 SMS: Merge two SRAM character's information

        This mode provides a method to produce an SRAM character from two
   other existing characters by mixing their traits. Actually, this is not
   very useful in itself. The reason I provided this mode was for people
   who want to have multiple suits for a character in the SRAM. If you have
   four different slots using the same character, but decide that you have
   to change something in the logic or moves, then you must change it in
   every copy of the character or re-enter and resave every suit. This is
   slow and annoying. Using this method, you can take the character data
   from the adjusted character, but still use the make of the other character.
   The general syntax of this mode is:

        sfhack sms (SRAM1) (Slot1) (Flags1) (SRAM2) (Slot2) (Flags2)
        (DestSRAM) (DestSlot)

        The first three arguments to the mode are the SRAM containing the
   first character to merge, the Slot in that SRAM that contains that
   character, and a string of character flags to denote which components
   of the new character record should come from from this character. The
   flags used are the same ones used for displaying a character in either
   the RDC, SDC, or MDC mode. For a list of these flags, either see the
   entry pertaining to the named modes or type 'sfhack sms' to see the
   usage instructions. After the first character's information, a second
   set of arguments consisting of the same three pieces of information must
   be provided for the second character to merge. Between the two characters,
   all available flags should be used; however, no flag should be included
   in both of the characters' flag strings. The final two arguments are the
   SRAM path and Slot number that specify where the merged character should
   be stored.
        As an example of this mode, let's assume that I am working on a
   Diamond Dallas Page character and want to have both his jeans outfit and
   his original DDP wrestling suit. Since SRAM slots only store one suit
   (without the Turbo File attachment), this requires two slots. Now, assume
   I adjust the logic drastically in the first slot, but don't feel like
   re-entering the suit for the second slot or its logic. For simplicity,
   assume the SRAM file is in the current directory and is named sfpwx.srm.
   Also, the first DDP is in slot 1 and the second one is in slot 2. Now,
   what I want to do is to set up the DDP in slot 2 with the new logic that
   I just entered in slot 1. So, I want to merge characters in slots 1 & 2
   and write the merge result back into slot 2. Now allow I need to figure
   out is what flags to use. Since the character in slot 1 is the updated
   version, I'll take all of the information except for the name and make
   from him. This makes the Flags1 argument ksvl and the Flags2 argument nm.
   The finished command line comes out to be:

        sfhack sms sfpwx.srm 1 ksvl sfpwx.srm 2 nm sfpwx.srm 2

 MSP: Set Module character's portrait & body graphic
 SSP: Set SRAM character's portrait & body graphic

        This mode allows the user to change the body graphic and portrait
   used by a character that is stored in either an SRAM or a module record.
   As with the other modes, the path to the module and module record index
   are needed to specify a module character to change, while the path to
   the SRAM and the Slot number are needed to specify an SRAM character to
   change. To specify the portrait and body graphic, index numbers are used
   that are available in the CODES document. The main purpose of these modes
   is to allow the user to access the hidden Giant Baba graphics. The
   syntaxes of these modes are:

        sfhack msp (Module) (Rec) (Portrait) (Body)
        sfhack ssp (SRAM) (Slot) (Portrait) (Body)

